Progressively load interactive elements of Dag Card#69806
Conversation
d11b093 to
9805025
Compare
shivaam
changed the title
|
@pierrejeambrun I have been experimenting with some ideas to make the UI snappier for displaying multiple rows of data. Could you take a look and share your thoughts? |
|
Please keep as a draft PR if you dont want it merged yet. |
So this PR is ready for review but not ready for merge. I thought a draft PR means that it is not ready for review but in this case I am looking for feedback from the community while doing some more testing on my end. Wondering what is the best way to say it is ready for feedback? |
|
I think a better safeguard is to keep it as a draft but then you can tag specific contributors in a comment to ask them to take a look. |
Sounds good. Since we are already here, if you get a chance can you also look at the PR and let me know if you have any thoughts. The improvement is marginal thought it makes the UI feel more snappier. |
There was a problem hiding this comment.
I feel like we should progressively load the interactive elements of a card instead of the cards themselves. Those are the slow to load elements. Batches of 5 cards would probably create some odd start-stop jitter during scrolling.
If a card is not in view, don't try to fetch or render any of the asset_expression, pause/unpause, delete button, favorite button, needs review tag. We can apply the same logic to the content of the table list too. So that the new dag run stats mad task instance stats also don't slow down rendering
9805025 to
7fdccc9
Compare
shivaam
changed the title
Great point. I like this idea and updated the PR to render the slower components only when the card is in the view. It took a few iterations. Let me know your thoughts. |
bbovenzi
changed the title
Backport failed to create: v3-3-test. View the failure log Run detailsNote: As of Merging PRs targeted for Airflow 3.X In matter of doubt please ask in #release-management Slack channel.
You can attempt to backport this manually by running: cherry_picker 4db892e v3-3-testThis should apply the commit to the v3-3-test branch and leave the commit in conflict state marking After you have resolved the conflicts, you can continue the backport process by running: cherry_picker --continueIf you don't have cherry-picker installed, see the installation guide. |
2 participants
Follow-up to #69681.
The DAG Card view can render up to 50 cards with 14 recent runs per card. On cached navigation, rebuilding hundreds of run bars and repeated interactive controls can delay the page even though most cards are below the viewport.
This change renders every card shell and its static DAG information immediately, while deferring the expensive interactive content until the card approaches the viewport:
The cards share one
IntersectionObserverper scroll root. Hydration is one-way, so scrolling away does not unmount controls or disturb focus or open menus. The observer finds the actual scrolling ancestor and applies a 600 pxrootMargin, avoiding a dependency on the newerscrollMarginoption. Keyboard focus entering a deferred card hydrates its controls, and browsers withoutIntersectionObserverfall back to eager rendering.This is intentionally not list virtualization. All card shells, DAG names, DAG identity links, sorting behavior, and browser find are available immediately. Interactive controls and recent-run links for fully offscreen cards appear when their card approaches the viewport or receives focus. All cards eventually hydrate, so the final page state is unchanged.
Screen.Recording.2026-07-21.at.7.18.52.PM.mov
Closes: #69609
Testing
pnpm tsc --noEmitprekUI hooksgit diff --checkWas generative AI tooling used to co-author this PR?
Generated-by: OpenAI Codex following the guidelines
{pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.